home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / rdisc / 90jul.min < prev    next >
Text File  |  1993-02-17  |  7KB  |  179 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Steve Deering/Stanford
  7.  
  8. RDISC Minutes
  9.  
  10. Agenda
  11.  
  12.    o Draft Specification
  13.       -  comments?
  14.       -  disposition?
  15.    o Implementations
  16.    o Black-Hole Detection
  17.  
  18. This was the fourth meeting of the Router Discovery Working Group.
  19.  
  20. The first and dominant item on the agenda was a discussion of the (late)
  21. July draft of the ICMP router discovery specification.  The following
  22. improvements and changes were agreed upon:
  23.  
  24.  
  25.    o Add a few sentences emphasizing that this is NOT a routing protocol
  26.      -- hosts are expected to rely on Redirects for finding the ``best''
  27.      first-hop router for any given destination.
  28.    o Make it even clearer than it already is that hosts must NOT
  29.      continuously send solicitations.
  30.    o Add a note explaining that, even though the timing values are
  31.      defined or configured in units of seconds, randomized intervals
  32.      should be computed at the best available resolution of the system's
  33.      interval timer.
  34.    o Fill in the missing ICMP Type values with officially-allocated
  35.      numbers.
  36.    o Change MAX_RESPONSE_DELAY from 5 seconds to 2 seconds.
  37.    o Change the upper bound on MaxAdvertisementInterval from (2^16 - 1)
  38.      to 1800 seconds (30 minutes).
  39.    o Even when a router is configured to use multicast instead of
  40.      broadcast, it may respond to a broadcast solicitation with a
  41.      broadcast advertisement (if not a unicast advertisement).
  42.    o When a router performs a graceful shutdown, it should send out
  43.      advertisements with a lifetime of 0, to flush its addresses from
  44.      the hosts' router lists.
  45.  
  46.  
  47. There was also discussion of adding an authentication field to the
  48. Router Advertisement message.  Deering argued that such a field could be
  49. appended to the existing message format if and when a non-null
  50. authentication type is defined for router discovery (i.e., the absence
  51. of an authentication field indicates ``null'' authentication.)  Noel
  52. Chiappa was not very happy with this proposal, but said he would check
  53. it out with the security gurus [which he subsequently did; apparently,
  54. Deering's proposed scheme will be acceptable].
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63. The group then agreed that, with the above modifications, the draft
  64. specification was ready to enter into the Internet standardization
  65. track.  Chiappa explained the necessary steps, as follows:
  66.  
  67.  
  68.    o Update the specification to incorporate the agreed changes and make
  69.      it available as an Internet Draft as soon as possible.
  70.    o After a one month comment period as an Internet Draft, if no
  71.      significant problems are uncovered, submit it to the IESG with the
  72.      group's recommendation that it be published as a Proposed Standard.
  73.    o Operational experience with multiple, independently-developed
  74.      implementations is generally required for advancement beyond
  75.      Proposed Standard status.  The decision to advance to the next
  76.      stage (Draft Standard) is up to the IAB, with advice from the IESG.
  77.  
  78.  
  79. That led to the next topic on the agenda:  implementations.  Andy
  80. Cherenson and Deering confirmed their previous commitment to generate an
  81. implementation of the protocol to run in user space on 4.3BSD and
  82. derived systems, perhaps starting from the source code for cisco's GDP
  83. demon; the implementation will include both the host and the router
  84. parts of the protocol.  John Veizades volunteered to do a Macintosh
  85. implementation of the host part of the protocol, and said he had an
  86. environment for testing the protocol's behavior under the simultaneous
  87. startup scenario (a rack of Macs on a single power circuit).
  88. Implementations for other platforms, and at the kernel level in BSD,
  89. were solicited, but no promises were made.  The importance of getting
  90. the major router vendors to implement the router part of the protocol
  91. and make it available for user testing was recognized; group members
  92. were encouraged to make that desire known to their favorite router
  93. vendors.
  94.  
  95. We then concluded that no further meetings of the Router Discovery
  96. Working Group would be necessary, if all goes according to plan.
  97. (Yah!!)  We discussed the possibility of transforming into a ``Black
  98. Hole Detection'' Working Group, and decided not to do so.  A document
  99. addressing the wider issue of host routing, of which black hole
  100. detection is a part, would be very valuable, but there was little
  101. enthusiasm for forming a new Working Group for that purpose; it might be
  102. taken up by the next incarnation of the Host Requirements Working Group,
  103. or perhaps some individual(s) will generate a document recommending (but
  104. not standardizing) good host routing strategies.
  105.  
  106. ACTION ITEMS
  107.  
  108.  
  109.    o Deering:  Ask the Internet Assigned Numbers Authority for two new
  110.      ICMP Types.
  111.    o Deering:  Revise the specification as agreed at this meeting and
  112.      submit it as an Internet Draft.  If no substantive, negative
  113.      comments are received during a one month comment period, recommend
  114.      the specification to the IESG as a Proposed Standard.
  115.    o Deering and Cherenson:  Implement both the host and router parts of
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.      the protocol as a user-level demon for 4.3BSD-derived systems, and
  125.      make it available to the Working Group and the wider internet
  126.      community for testing and validation of the protocol.
  127.    o Veizades:  Implement the host part of the protocol for Macintosh
  128.      and test it in an environment with many hosts on the same subnet
  129.      (especially under the simultaneous startup scenario).
  130.    o Everyone:  Encourage your favorite router vendor to do a prototype
  131.      implementation of the protocol, for in-house and customer- site
  132.      testing.
  133.  
  134.  
  135. Attendees
  136.  
  137.  
  138. Zorica Avramovic         zorica@sparta.com
  139. Art Berggreen            art@opal.acc.com
  140. Larry Brandt             lbrandt@sparta.com
  141. Eric Brunner             brunner@monet.berkeley.edu
  142. Andrew Cherenson         arc@sgi.com
  143. Steve Deering            deering@pescadero.stanford.edu
  144. Robert Elz               kre@munnari.oz.au
  145. Karen Frisa              karen@kinetics.com
  146. Robert Gilligan          gilligan@sun.com
  147. Tony Hain                alh@eagle.es.net
  148. Steven Hubert            hubert@cac.washington.edu
  149. Ole Jacobsen             ole@csli.stanford.edu
  150. Ken Jones                uunet!konkord!ksj
  151. Michael Karels           karels@berkeley.edu
  152. Stev Knowles             stev@ftp.com
  153. Alex Koifman             akoifman@bbn.com
  154. Sam Lam
  155. Gregory Lauer            glauer@bbn.com
  156. John Lekashman           lekash@orville.nas.nasa.gov
  157. Solomon Liou             solomon%penril@uunet.uu.net
  158. Yoni Malachi             malachi@polya.stanford.edu
  159. Tony Mason               mason@transarc.com
  160. Paul McKenney            mckenney@sri.com
  161. John Moy                 jmoy@proteon.com
  162. John Mullen
  163. Stephanie Price          cmcvax!price@hub.ucsb.edu
  164. Tim Seaver               tas@mcnc.org
  165. Deepinder Sidhu          sidhu@umbc3.umbc.edu
  166. Craig Smelser
  167. Frank Solensky           solensky@interlan.interlan.com
  168. Martha Steenstrup        msteenst@bbn.com
  169. Zaw-Sing Su              zsu@tsca.istc.sri.com
  170. Paul Tsuchiya            tsuchiya@thumper.bellcore.com
  171. John Veizades            veizades@apple.com
  172. Carol Ward               cward@spot.colorado.edu
  173. Jonathan Wenocur         jhw@shiva.com
  174. Walter Wimer             ww0n+@andrew.cmu.edu
  175.  
  176.  
  177.  
  178.                                    3
  179.